Sumo LogicにVPCフローログのアウトバウンド通信ログだけを取り込んでみた

酒井剛

2022.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

SIEM製品にログを入れる時、料金気になりますよね。
出来る限りログはそのまま保存しておきたいところではありますが、ログの保存料＝?となると、やはり本当に必要なログだけを取りたいものです。

Sumo LogicではProcessing Ruleというものを使って、取り入れるログを正規表現を使って取捨選択することができます。今回は、AWSログで特に容量が多くなりがちだが、分析の対象として非常に効果的なVPCフローログの取り込みをフィルタして、Sumo Logicのコストを抑える方法についてご紹介したいと思います。

Processing Ruleとは

Sumo Logicへのデータ取り込み時に、ログメッセージに含まれる特定のパターンに合致した際に、そのメッセージの取り込みを制御したり、メッセージを加工したりする時に利用する機能となります。

取り込み制御については、フィルターという機能で下記の2種類のタイプがあります。

Exclude messages that match: ブラックリストとして機能し、指定したパターンと合致したメッセージの取り込みをしない（合致しなかったメッセージは全て取り込む）
Include messages that match: ホワイトリストとして機能し、指定したパターンと合致したメッセージのみを取り込む（合致しなかったメッセージは全て取り込まない）

メッセージ加工については、アクションという機能で下記の2種類のタイプがあります。

Hash messages that match: 機密情報のハッシュ化として機能し、指定したパターンと合致したメッセージ部分をランダムなハッシュ値に変換した後、メッセージを取り込む
Mask messages that match: 機密情報のマスク化として機能し、指定したパターンと合致したメッセージ部分をカスタマイズ可能な文字に変換した後、メッセージを取り込む

取り込むログのフォーマットを理解する

Processing Ruleを活用するために、特定の処理をさせる条件となるメッセージパターンを定義する必要があります。そのために、対象となるログフォーマットを押さえましょう。今回は、VPCフローログですので、AWSの公式ドキュメントの方で、出力されるログのフォーマットを確認します。

VPCフローログを出力するための設定の際に、デフォルトの形式でログを出力させるかカスタム形式で出力するフィールドを決めることができます。今回はデフォルト形式でログを出力していることを仮定して進めていきます。
ドキュメントによると、

次に表に、フローログレコードの使用可能なすべてのフィールドを示します。[Version (バージョン)] 列には、フィールドが導入された VPC フローログのバージョンが表示されます。デフォルトの形式には、すべてのバージョン 2 フィールドが含まれ、順番はテーブルと同じです。

とありますので、ドキュメント内のテーブルを確認すると以下のようなログフォーマットとなっていることが分かります。

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status

では、VPCのログフォーマットを理解したので、今回やりたいこととなるアウトバウンド通信のログを特定するための条件パターンについて考えます。

VPCフローログの通信方向について

VPCフローログのメッセージ内容から、そのログメッセージがアウトバウンド通信なのか、インバウンド通信なのか（あるいはインターナル通信＝AWS間の通信）を判断する必要があります。上記のログ出力の設定で、カスタム形式を選んで、version 5にある「flow-direction」の値から判断することも可能なのですが、今回はデフォルト形式のversion 2のフィールドのみで考えてみます。
そこで「srcaddr」と「dstaddr」に注目してみます。

この２つ、「srcaddr」がグローバルIPで「dstaddr」がプライベートIPだった場合、そのメッセージはインバウンドの通信となります。
逆に「srcaddr」]がプライベートIPで「dstaddr」がグローバルIPだった場合、そのメッセージはアウトバウンドの通信となります。
また、「srcaddr」と「dstaddr」の両方がプライベートIPだった場合、その通信はインターナル通信であると判断することが可能です。
そうすると、「dstaddr」がプライベートIPだった場合、インバウンド通信かインターナル通信と判断ができます。「dstaddr」がプライベートIPだったメッセージの取り込みを拒否して、その他のメッセージを取り込むルールにするとアウトバウンド通信のみを取り込むことができそうです。

前の「Exclude messages that match」がこれに該当します。

やってみる

それでは、Sumo Logic側でログ取り込みの設定をしていきます。

Sumo Logicにログインして左ペーンのManage Data > Collectionに進んでいきます。

Hosted CollectorのVPC FlowログのソースのEditをクリックします。

※Hosted Collectorを作成していない場合は作成してください。VPC flow logsのデータ取り込み設定（ソースの作成）が出来ていない場合は、ソースを作成してください。 S3バケットに保存したAWSログの取り込み方法については、弊社のブログでも紹介しています。新規作成する場合にはこちらをご参照ください。

次に画面の一番下の方まで下がっていくと、Processing Rules for Logsという項目が閉じられています。ここを開き、Add Ruleを選択します。　　

任意のルール名と、Filterに先程考えた条件パターンを入れます。
条件パターンに利用できる正規表現はRE2シンタックスとなります。使えるシンタックスはこちらをご確認ください。

^2 .* .* .* ((127\.)|(169\.254\.)|(10\.)|(172\.1[6-9]\.)|(172\.2[0-9]\.)|(172\.3[0-1]\.)|(192\.168\.)).*

各フィールドが空白で区切られ「dstaddr」が５番目のフィールドになります。５番目のフィールドがプライベートIPとなるメッセージの取り込みを拒否します。ですので、Typeは「Exclude messages that match」を選択してApplyして、Saveします。

確認してみる

アウトバウンド通信だけを取り込む設定ができたので、きちんと想定通りにログが取り込まれているかを確かめます。
PCのコンソールからVPC内のEC2インスタンスに対してpingをしてみます。外部からのインバウンド通信になりますので、この通信に対するVPCフローログはSumo Logicに取り込まれない想定です。※Timeoutになっていますが、VPCフローログではDENYで記録されるので特に問題ありません。

$ ping <VPC内のインスタンスのPublic IP>
PING <VPC内のインスタンスのPublic IP> (<VPC内のインスタンスのPublic IP>): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C

次にVPC内のEC2インスタンスに接続して、このインスタンスからプライベートIPアドレスにpingをしてみます。AWS内の他のVPCへのインターナル通信になりますので、この通信に対してのVPCフローログもSumo Logicに取り込まれない想定です。

$ ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
^C
--- 10.1.1.1 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16372ms

最後にVPC内のEC2インスタンスから、パブリックIPアドレスにpingをしてみます。アウトバウンドの通信になりますので、この通信に対してのVPCフローログのみがSumo Logicに取り込まれる想定となります。

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=105 time=2.68 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=105 time=2.64 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.641/2.661/2.681/0.020 ms

Sumo Logicのコンソールでログを検索してみます。それぞれpingで通信したIPアドレスで検索すると、想定通りアウトバウンドの通信だけが取り込まれていることを確認できました。

まとめ

今回は、Sumo LogicのProcessing Ruleを使って、特定の条件に合致するログだけを取り込む方法についてご紹介しました。Sumo Logicにログを取り込むことで、継続したログの可視化や柔軟な検索ドリルダウンによるセキュリティ強化を実現することができますが、コストによる心配はつきません。
セキュリティインサイトを高めるために必要なログを把握した上で、コストを抑えるため不要なログを絞っていくことはSIEM運用にとって重要な課題となってきます。

ぜひ、この機能を活用して最適化を進めていく一助としてください。